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ABSTRACT 



The Expert System Advisor for Aircraft Maintenance Scheduling (ESA AMS) was 
originally proposed in 1985 to assist in the scheduling of maintenance discrepancy repair in 
the organizational squadron environment. This dynamic environment produces a 
continuous flow of maintenance documentation from each maintenance action. Presently 
there exists no single system for the maintenance expert to retrieve this information to assist 
him, or her, in the critical maintenance decision making process. 

This thesis addresses the design of the ESAAMS database which is of paramount 
importance to the expert system. Research on the use of the Naval Aviation Logistics Data 
Analysis (NALDA) database for a personal computer-based database, is documented. 
Review of other existing naval aviation database systems are included in this research. 
Based on interviews with experienced fleet aviation maintenance managers, a prototype 
database design is produced. This thesis concludes with recommendations for further 
study based upon the findings of this research. 
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I. INTRODUCTION 



A. BACKGROUND 

Today’s Navy and Marine Corps maintenance managers are faced with systems which 
are continuously becoming more sophisticated and complicated to maintain. Guided by the 
Naval Aviation Maintenance Program (NAMP), the maintainer is responsible each day for 
optimizing the operational availability of his or her assigned assets. To accomplish this 
monumental task a continuous flow of information must be readily available to him/her to 
make accurate and timely decisions. 

Over the years, access to information has been limited to local records and feedback 
reports (forwarded from data processing facilities) that are 60 to 90 days old. In today's 
dynamic maintenance environment this way of doing business is no longer acceptable for 
the maintenance manager. In an age of automated information systems and real time access 
to records, a reliaole information system is not only possible, but must be made available to 
maintenance managers. 

The Expert System Advisor for Aircraft Maintenance Scheduling (ESAAMS) 
introduced by McCaffrey [Ref. 1] in 1985, is the key to the way maintenance information 
can be processed and put to use in the Navy of the 21st century. This system concept 
incorporates the use of an expert system to use the information generated in the 
organizational aviation maintenance activity to assist in the scheduling of the daily 
maintenance workload. 

This thesis is a follow-on to research previously conducted which will ultimately 
produce the personal computer (PC) based ESAAMS system. This research will directly 
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build on the earlier work of McCaffrey [Ref. 1J and Burpo [Ref. 2] and to a lesser extent 
on the works of Chase [Ref. 3] and Stone [Ref. 4]. 

B. OBJECTIVES 

The objective of this thesis is to review the contents of Naval Aviation Logistics Data 
Analysis (NALDA) database and other aviation maintenance database systems, and design 
a PC-based prototype database for ESAAMS using NALDA data. Potential links to other 
data management systems will also be investigated. 

The following primary research questions will be addressed: 

• What data contained in the NALDA database system are germane for use in building 

the ESAAMS main database? 

• What uses/benefits would such a database provide an organizational maintenance 

activity? 



Secondary research questions include: 

• Are other databases in addition to NALDA required for the proper operation and 

maximum benefit of ESAAMS? 

• What do the "experts" in the aviation maintenance community want from a 

management information system? 

C. SCOPE, LIMITATIONS AND ASSUMPTIONS 

Development of the ESAAMS concept is so broad that this thesis will only address 
issues involving ESAAMS database design. This research concludes with 
recommendations for future use of the ESAAMS database structure as a standalone DBMS 
and the future of ESAAMS in general. Design and discussion of other essential 
components of the ESAAMS system are deferred for future research projects. 

User input for this research was conducted in an informal question and answer format 
The sample was limited to personnel assigned to the activities addressed below and the 
interview format was structured to allow a subjective vice objective input. While this form 
of sampling is not scientific by nature, the authors feel that the views and opinions of those 
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interviewed do reflect some of the primary concerns of the expats assigned within the F/A- 
18 community. These opinions and views do not necessarily encompass views and 
opinions from all aviation maintenance communities Navy-wide. 

D. RESEARCH METHODOLOGY 

Data collection for this project was conducted both on-site and through telephone 
conversations. Activities contacted include: NAVAIR Program Manager Air 270 (PMA- 
270); Naval Aviation Maintenance Office (NAMO-42); Commander Strike Fighter Wing 
Pacific Fleet Code 70; Naval Aviation Maintenance Training Group Detachment 
(NAMTRAGRUDET) Lemoore, CA; Aviation Intermediate Maintenance Department 
(AIMD), Naval Air Station Lemoore, CA.; Strike Fighter Squadron 25 (VFA-25); Strike 
Fighter Squadron 113 (VFA-113); members of the NALDA Users Assistance 
Group.(NAMO-622C); and a cadre of Aerospace Engineering Duty Officers assigned to the 
Naval Postgraduate School, Monterey, CA. 

A thorough review of current fleet instructions, fleet system proposals and supporting 
program literature was conducted to provide the most current system and program status. 
Information assembled includes some yet unpublished research material to reflect the state- 
of-the-art in current Navy management information system development. 

Description of the aviation maintenance process was based on the governing aviation 
maintenance instructions and the authors' personal experience at three types of Naval 
aircraft squadrons, and an Aircraft Intermediate Maintenance Department (AIMD). 

E. THESIS ORGANIZATION 

The remaining chapters of this thesis are as follows: 

II. DATABASE SYSTEMS . A general discussion of database and Database 
Management Systems (DBMS). DBMS concepts and objectives, database models, 
relationships, and database manipulation are discussed. 
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III. THE AVIATION MAINTENANCE ENVIRONMENT . A brief description of 
the Naval Aviation Maintenance Program (NAMP) and how it relates to an Organizational 
Maintenance Activity (OMA) are discussed. The basic levels of maintenance and 
maintenance data reporting arc examined. 

IV. NALDA DATABASES . A look into the NALDA program history, database 
structure, contents, and applicability to ESAAMS are examined. 

V. NON-NAT .DA DATABASES . An examination of other databases available to the 
maintenance expert and for possible interface with ESAAMS is conducted. A brief 
background and future uses for each database system are provided. 

VI. MAINTENANCE COMM UNITY USER INPUT . Reactions of experts to the 
ESAAMS concept and potential uses of the NALDA database are examined. 

VII. DATABASE DEVELOPMENT AND PROGRAM DESIGN . Design and 
construction of a prototype database and DBMS compiled from the NALDA database 
system is examined. 

VUI. CONCLUSIONS AND RECOMMENDATIONS . A summary of research 
question findings and future concern s/recommendations are provided. 
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II. THE AVIATION MAINTENANCE ENVIRONMENT 



A. INTRODUCTION 

Naval Aviation Maintenance is a dynamic and constantly changing field. From a land- 
based, routine training flight to the high tempo of carrier-based flight operations, the 
squadron maintenance department is responsible for providing safe, mission capable (MC) 
aircraft on a continual basis. The success, or failure, of an aviation squadron can, and 
usually does, rest on the professionalism and expertise of the maintenance department. It is 
essential that critical decisions are made in a timely, accurate and precise manner. To 
accomplish this monumental task, the maintenance "expert" must have the right information 
available in the right place at the right time. 

Presently, critical decisions are made under the guidelines of the Naval Aviation 
Maintenance Program (NAMP) and from a combination of experience, governing 
instructions, and expert knowledge. This decision making process is applied to every 
maintenance action. The resulting action is recorded and sent upline as maintenance data. 
With the vast quantities of data that are transmitted upline each day by every' maintenance 
organization, there remains no single retrieval source for this data to assist the 
organizational maintenance expert in making day-to-day scheduling decisions. The current 
information system environment is incapable of producing the types of information needed 
to optimize squadron mission readiness decisions. An expert system, such as ESAAMS, 
requires access to this wealth of data available in both the Navy’s Aviation Maintenance and 
Material Management System (AV-3M) and the Naval Aviation Logistics Data Analysis 
(NALDA) system. Specifically, ESAAMS will require the average elapsed maintenance 
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time to remove and replace a part, and the historical failure rate of a component in relation 
to other components in an aircraft system. 

B. THREE LEVELS OF MAINTENANCE 

To fully understand the scope of the NAMP it is important to understand the 
environment of aviation maintenance. The NAMP objective is "...to achieve and 
continually improve aviation material readiness.. .with optimal use of material, manpower, 
and funds."[Ref. 5: p. 2-1] This objective is translated into a primary philosophy which is 
to repair equipment at the maintenance level, which ensures optimal economic use of 
resources. 

The NAMP divides aviation maintenance into three distinct levels, each level linked to 
the other through the Naval Supply System. The three levels of repair are the 
organizational level (O-level), intermediate level (I-level), and the depot level (D-level). 

1. Organizational Level 

The organizational level encompasses maintenance traditionally considered to be 
the most basic and simple tasks required for repair of assigned aviation equipment [Ref. 6: 
p. 108]. O-level maintenance functions include inspection, servicing, handling, on- 
equipment corrective and preventive maintenance, technical directive compliance, and 
administrative record keeping and reporting [Ref. 5: p.3-1]. Truly, the other two levels are 
of limited value without a properly managed and operated maintenance program at the 
Organizational Maintenance Activity (OMA). O-level maintenance of assigned equipment is 
the responsibility of the using or reporting activity. The success of the maintenance effort 
directly affects aircraft availability and Naval aviation readiness. The importance of a high 
readiness state cannot be over-emphasized. 
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2. Intermediate Level 

The intermediate level of maintenance concentrates on calibration, repair or 
replacement of damaged or unserviceable parts, components or assemblies; the 
manufacture/fabrication of non-available parts; and the provisions for technical assistance to 
O-level activities. Maintenance is accomplished in an off-equipment environment dealing 
mainly with major system and sub-system aircraft components. The I-level directly 
supports the O-level by repairing and then returning parts to the supply system. 

3. Depot Level 

The third level of repair is preformed at Naval Aviation Depots (NADEP) or by 
NADEP field teams sent to accomp sh on-site repair. D-level maintenance represents the 
highest level of repair and accomplishes both in-depth on-equipment and off-equipment 
repair and modifications. Maintenance at this level consists of major overhaul (rework) or 
complete re-manufacturing of parts, assemblies, subassemblies, and end-items, including 
the manufacture, modification, testing, and reclamation of parts as required. (Ref. 7 p.3-2] 
D-level maintenance supports the other two levels of maintenance directly and through the 
supply system. 

C. THE ORGANIZATIONAL MAINTENANCE ACTIVITY 

Our focus in this thesis is on the organizational level or OMA. The most common 
OMA is the aviation squadron. We will concentrate our attention and research here. Chase 
[Ref. 3] points out "...the two broad areas of aircraft maintenance are— a Planned 
Maintenance System (PMS) and a Maintenance Data System (MDS)." Both of which are to 
"insure the highest state of aircraft readiness and reliability at the lowest cost in men, 
money, and material." [Ref.8: p. 1-3] 

In addition to the scheduled requirements, the maintenance manager is faced with a 
daily array of unscheduled requirements to maintain aircraft availability. This area of 
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aviation maintenance typically absorbs a greater part of the total maintenance time than does 
scheduled maintenance. 

The MDS is a management information system designed to provide statistical data for 
use at all aviation maintenance and management levels. The system collects data from 
every maintenance action performed on an aircraft or component of an aircraft or support 
system. The data also includes input about parts availability and usage, man-hours 
expended in the repair process, equipment configuration, and flight information. 

The system is designed so that each worker, when performing a job, converts a 
narrative description of the job into codes and enters coded information on standard forms 
or source documents. These source documents are collected and transmitted to a data 
services facility (DSF) where information is converted into machine records. The DSF 
then uses the machine records to produce periodic report listings summarizing the 
submitted data. These reports are supplied to maintenance supervisors to provide assistance 
in planning and directing the maintenance effort. [Ref 10: p. 2-1] 

1. Planned Maintenance System 

The Planned Maintenance System (PMS) is an aircraft-specific maintenance plan 
which specifies applicable maintenance actions to be performed at predetermined 
(scheduled) intervals. Contained in a series of publications, it specifies the minimum 
maintenance that must be accomplished, the scheduled maintenance. [Ref. 3] The 
publications provide a basis for planning, scheduling, and actual performance of scheduled 
maintenance requirements. [Ref. 9 pp. 10-21] The PMS is the responsibility of the 
Maintenance Department within each squadron. Adherence to the PMS optimizes aircraft 
life and safety of operation during its life cycle. It ensures, when properly conducted, that 
"all aeronautical equipment receive required servicing, preventive maintenance, and 
inspection." [Ref. 9: p. 6-5] 
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2. Maintenance Control 

The first principle of maintenance is: Maintenance Control must control 
maintenance! While sounding like a play on words, this corollary is the foundation of 
the success or failure of the entire maintenance program. Maintenance control is the focal 
point, "control center", of the squadron maintenance program. In this "hub" of the 
Maintenance Department, the maintenance workload is coordinated and prioritized. 
Maintenance tasks are then assigned to each supporting work center to fulfill the days 
requirements. See Figure 2-1 below. 

Maintenance control's responsibility does not apply only to the PMS and 
unscheduled maintenance. A primary mission of every OMA is to meet the daily flight 

schedule! To accomplish this task a combination of variables must be considered: 

• Daily flight schedule aircraft requirements 

• Scheduled maintenance requirements (calendar/phase inspections, etc.) 

• Daily array of unscheduled "gripes" for each aircraft 

• Personnel requirements (work center manning, training, etc.) 

• Support equipment availability 

• Parts availability (repairable/consumable) 

• Future command requirements (detachments/deployments) 

• Requirements specified by higher authority (inspections, special exercises, technical 

bulletins/directives) 

• Support facility availability (IMA personnel available, holidays, etc.) 

All of these variables must fit into a "master schedule" and be precisely coordinated to 
maximize readiness and aircraft availability. This is maintenance control's biggest task. 

This major undertaking is the responsibility of the Maintenance Officer (MO) and 
his direct subordinates. The master plan, commonly known as the maintenance plan, is 
normally developed by the senior enlisted member in the maintenance control division, the 
Maintenance Master (or Senior) Chief (MMC), in concert with the Maintenance/Material 
Control Officer (MMCO); the Assistant Maintenance Officer(AMO), where personnel or 
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training is involved; and the Maintenance Control Chiefs (MCC). Figure 2-1 depicts the 
organization of the maintenance department. 




Figure 2- 1 . OMA Maintenance Department Organization 1 



The Maintenance Master Chief (Senior Chief when no Master Chief is assigned), 
is the resident enlisted expert in maintenance control. It is usually his decision making that 
sets the pace of the entire maintenance effort. Ideally, the MMC is the most experienced 
member of the Maintenance Control team and is well versed in every facet of the NAMP 
and an expert on the type of aircraft being maintained. It is important to assign a capable 



1 Figure 2-1 is an adaptation of Figure 3-3 in Ref. 9: p 3-3. 
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leader who can maintain the continuity between maintenance control and the maintenance 
production work centers, which may also have Chief Petty Officers (CPOs) assigned 

Working directly for the MMC are the MCCs who generally manage the "leading 
edge" or minute-by-minute flow of maintenance. Their decision making process is made in 
real-time, commonly split second input from the entire maintenance arena. They put the 
maintenance plan into effect but must vary their structure as internal and external influences 
demand. 

The Maintenance/Material Control Officer and the Maintenance Master Chief are 
generally involved with the program in a broad sense. Master scheduling and long range 
strategic planning typically absorb a large quantity of their time. Deriving and publishing a 
monthly schedule of maintenance, not surprisingly known as the Monthly Maintenance 
Plan (MMP), reflects this strategic planning. These two individuals are widely considered 
to be the experts in the maintenance environment. Their combination of maintenance 
experience, understanding of the NAMP, and knowledge of the aircraft, make them 
invaluable to the maintenance process. 

D. AV-3M REPORTING 

The Maintenance Data System and one of its major sub-groups, the Aviation 
Maintenance and Material Management (AV-3M) System, provides the principal means for 
the collection of maintenance data. Data is collected from every maintenance action 
performed on every item of aeronautical equipment processed at the O and I-levels, 
including some input from D- level actions. 

Reporting of maintenance actions accomplished at the O-level is primarily directed into 
the Naval Aviation Maintenance and Material Management (AV-3M) System by the use of 
OPNAV Form 4790/60, the Visual Information Display System/Maintenance Action Form 
(VIDS/MAF) and OPNAV Form 4790/42, Support Action Form (SAF). These documents. 
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(referred to as source documents) are screened for accuracy at the OMA and submitted to 
the local Data Services Facility (DSF). This is commonly known as the local cycle.[Ref. 
10: para 2.1.3] 

The source documents are again screened, corrected, and converted into ASCII or 
EBCDIC machine language at the DSF. When the documents have been verified, the 
information is transmitted to the Naval Aviation Maintenance Support Office (NAMSO) 
where it is compiled with input from all other DSFs. NAMSO then provides AV-3M 
monthly feedback reports to the originating activities. It also sends the data to the Naval 
Aviation Logistics Data Analysis (NALDA) database. This is the central repository of 
aviation maintenance data. Figure 2-2 depicts the current AV-3M data flow. The Enhanced 
Comprehensive Asset Management System (ECAMS) will be discussed in Chapter V. 
Further discussion of NALDA will be reserved for Chapter IV. 
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Figure 2-2. Current AV-3M Data Flow 



E. SUMMARY 

The dynamic environment of naval aviation maintenance requires the maintenance 
expert to make split-second decisions accurately and with professional confidence. To 
accomplish this task, he or she must be provided with the right information at the right time 
in the right place. There is a wealth of historical information available in the NALDA 
database. The data consists of hundreds of maintenance actions that are accomplished 
daily, processed for accuracy, and then are transmitted to the main NALDA database. The 
processing of this data into information, and making it available to the maintenance expert, 
could be a valuable asset to the planning and scheduling of organizational maintenance. 
The composition and use of the NALDA database is the subject of the next chapter. 
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III. DATA BASE SYSTEMS 



A. INTRODUCTION 

This chapter introduces database and database management system concepts. An 
expert system, such as ESA AMS, contains a knowledge base, an inference engine, and a 
user interface. The knowledge base contains the rule base and access to the database. The 
database is the repository of facts that, together with the rules in the knowledge base, will 
be used by the inference engine for the expert system. Database management system 
concepts and objectives, data models, relations, and how data is manipulated to perform 
required applications, will be discussed. 



B. DATABASE TECHNOLOGY 

Before the introduction of database concepts, businesses and organizations used file 
processing systems to process records and produce information. These systems stored 
groups of records in separate files and processed them separately. Although these systems 
were a great improvement from the laborious manual processing, there are several 
limitations: 

• Data is separated and isolated 

• Data is often duplicated 

• Application programs are dependent on file formats 

• It is difficult to represent complex objects using file processing systems [Ref. 1 1: p. 

7] 

To overcome the limitations of file processing systems, database technology was 
developed. A database is a collection of integrated, shareable, and non-redundant records. 
These records are interrelated by specific relationships. [Ref. 12: p.5] An integrated 
database provides an organization with greater access to information, better control and 
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easier program application development. David M. Kroenke and Kathleen A. Dolan define 
a Database Management System (DBMS) as: 

"...a program (or a set of programs) that allows stored data to be integrated, 
reduces data duplication, ensures data integrity, eliminates program dependency on 
file formats, and allows complicated objects to be easily represented and retrieved. 
Briefly, a DBMS is a software system that is capable of supporting, manipulating, 
and managing a database.'fRef. 1 1 : p. 9] 

C. DATABASE MODELS 

There are three basic data models or structures used in Database Management Systems: 
hierarchical, network, and relational. 

1. Hierarchical Model 

The hierarchical data model represents data relationships using hierarchies or 
trees. As Figure 3-1 illustrates, a tree or hierarchy consists of a number of nodes arranged 
in a top-down sequence. Every node represents a data element. Every node is related to 
another node at the next higher level. The higher node is called the parent and the nodes 
below the parent are the children. A child can only have one parent but a parent can have 
several children. The top-most parent is often labeled the root while the bottom most 
children are called the leaves (hence, the name TREE). IBM first introduced this structure 
for use in their Data Language I (DL/I) DBMS. 
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Figure 3-1. Hierarchical Model 
2. Network Model 

In a network model, the degree of sophistication is carried up to the next level by 
letting children have more than one parent The basic hierarchical or tree structure approach 
is still used. See Figure 3-2. The most widely known network model is the CODASYL 
DBTG (Conference on Data Systems Languages, Data Base Task Group). The 
development of CODASYL is very complex. The American National Standardization 
Institute (ANSI) never adopted CODASYL as a national standard. 
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3. Relational Model 

The relational model, with its accompanying SQL (Structured Query Language), 
was accepted as the national standard by ANSI in 1986. 

A relational model conceptually stores data in a way that a user can easily 
understand and relate to. It was first introduced by E. F. Codd and was derived from the 
mathematical definition of relations, that is, a relation is a subset of the Cartesian product of 
its underlying domains. The relational model is based on the concept that data is organized 
and stored in two-dimensional tables called relations [Ref. 13 p. 131]. The columns are 
called attributes while the rows are called tuples. A row in a relation or table is like a record 
with its own characteristics. Figure 3-3 shows a complete example of a relational database 
organization where one table is called MAINT_ACTION and the other is called 
INCORPORA TED_TD. In Figure 3-3 , the first row contains a document number 
called SWP 4826 . a maintenance level of Q, a malfunction code of 123 . an action taken 
code of 5, and man-hour reading of (L5. The columns, called attributes, represent fields or 
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data elements. So in Figure 3-3, the entries under DOC_NUM are fields of document 
numbers, entries under MAINT_LVL are fields of maintenance levels, etc. The entire 
table of rows and columns is roughly the equivalent of a file. A file contains records and 
records contain fields or data elements. Unlike mathematical relations, however, database 
relations are time-varying since tuples (rows) may be inserted, deleted, or updated [Ref. 
1 1: p. 186]. In simple terms, we have a file of maintenance actions and another file of 
incorporated Technical Directives. 

Each tuple or row in a relation or table is identified by a key. A key is a group 
of one or more attributes that uniquely identifies a row [Ref. 1 1: p. 139]. Going back to 
Figure 3-3 once more, the first row of MAINT_ACTION can be uniquely identified by 
the DOC_NUM SWP 4826. All the other rows have their own unique DOC_NUMs. It 
is possible that a row can have more than one attribute that can become a key. These 
attributes are called candidate keys and they can be composed of a primary key and 
foreign keys. A primary key is an attribute that can uniquely identify a row or a tuple. A 
foreign key is a candidate key that is taken from another table or relation and placed as an 
attribute (column) in another table in order to form a relationship between the two tables. 
These keys are selected to uniquely identify the row. In Figure 3-3, the table 
INCORPORATED_TD has two candidate keys, namely, DOC_NUM and 
BASIC.NUM. EMCORPORATED_TD is related to MAINT.ACTION through 
DOC.NUM. DOC.NUM is a foreign key to INCORPORATED.TD since 
BASIC_NUM can be its primary key. It is possible for the primary key and foreign key 
to be the same. For instance, in Figure 3-3, DOC_NUM can be the primary key for both 
the INCORPORATED TI) and M AINT_ A C TI ON since it can uniquely identify a 
row from either table. 
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Figure 3-3. Relational Database Model 
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4. Normalization 



Normalization is the process of gathering data items (or attributes) into relations. 
The goal of a good logical database design is to represent objects or entities in the database 
using relations that (1) provide the data needed to construct user objects (or tables) and (2) 
are robust enough to allow rows to be inserted, deleted, and modified without resulting in 
inconsistencies or errors in the stored data. [Ref. 1 1: p. 133-134] 

5. Relationships 

In order to have an efficient operation for a DBMS, proper data base design is 
extremely critical. It is necessary to preclude an excessive amount of data redundancy, 
inadvertent deletion of data, and presence of data anomalies. Correct relationships between 
entities or objects are imperative to achieve a proper logical design. Relationships between 
entities can be classified in three ways: 

• One-to-one 

• One-to-many 

• Many-to-many 

a. One-to-one Relationships 

A one-to-one (1:1) relationship is the simplest form. Given an Object A and 
an Object B, a one-to-one relationship exists if A contains B as a single-valued property 
(or attribute), and either B contains A as a single-valued property or B does not contain A. 
Hence, there can only be one occurrence for an attribute in an object The key of one of the 
relations must be stored as an attribute of the other in order to link them together. [Ref. 1 1 : 
pp. 169-174] 

An example of this kind of relationship can be shown using Appendices A 
and B. In Appendix A, the table or object Main tenance_ Action is related one-to-one 
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(1:1) with the object Incorporated_TI). This is denoted by the absence of "mv” or 
multiple value after object Incorporated_TD inside the object Maintenance_Action. 
In other words, for each occurrence of a Maintenance_Action there is only one 
occurrence of Incorporated_TD. In Appendix B, the graphical logical representation of 
the database shows the 1 : 1 relationship again by the straight line connection between these 
two objects without the arrow tail. Note in Appendix B that the primary keys JCN and 
WC of Maintenance_Action are used as foreign keys for Incorporated_TD. 

b. One-to-many Relationships 

A one-to-many (1:N) relationship occurs when a record of one type is 
related to potentially many records of another type. [Ref. 1 1 : p. 174). The terms parent and 
child are sometimes applied to records in one-to-many relationships. The parent record is 
on the one side of the relationship and the child record is on the many side. The key of the 
parent relation must be stored as an attribute of the child relation. 

Using Appendices A and B to show an example of a one-to-many (1:N) 
relationship, let’s take the objects End_Item and Maintenance_Action. For every 
occurrence of an Endltem there can be many Mai n ten ance_Acti ons. This follows the 
same logic in the business environment of aviation maintenance. For every aviation end 
item, which can be an aircraft system or part, there can be multiple maintenance actions 
taken. Appendix A shows the 1:N relationship between these two objects by the presence 
of "mv" after Maintenance_Action inside the End_Item object. Appendix B shows 
this relationship once more by the arrow tail symbol on Maintenance_Action. 

c. Many-to-many Relationships 

In a many-to-many (M:N) relationship a record of one type is related to 
many records of the second type and a record of the second type is related to many records 
of the first type. Many-to-many relationships cannot be directly represented in relations as 
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one-to-one (1:1) or one-to-many (1:N) relationships because deletion and insertion 
anomalies will occur in the database. The solution to the problem is to create a third relation 
that shows the correspondence of the objects. This relation is called an intersection 
relation. Each record in an intersection relation contains the keys of each of the related 
records in the two relations. [Ref. 1 1: pp. 178-183] 

Appendices A and B don't show a many-to-many relationship. To show an 
example of a many-to-many relationship, let us take two imaginary objects called 
Personnel and Squadron. Aviation personnel can belong to many squadrons (maybe 
not at the same time) and a squadron can have many personnel. Since these two objects are 
both multi-valued, in order to create a database relationship an intersection object must be 
created. This object can be called Squadron_Personnel and will contain the keys of 
each of the objects. 

D. WHY CHOOSE A RELATIONAL DATABASE MODEL FOR ESAAMS? 

As mentioned earlier, a relational database is stored conceptually in a way the user can 
understand and access directly. Relations, being two-dimensional tables, are easier to 
comprehend and deal with by non -programming oriented users. Users are presented with a 
single and consistent data model or structure. There is no need for concern on the 1:N 
versus the M:N relationships as in the hierarchical and network models. The relationships 
are stored in the data themselves. 

There is more data independence, flexibility, database processing power, and security 
in a relational model. The model permits relational completeness that can be transparent to 
a non-technical user. It also facilitates good database design. Potential aviation 
maintenance users will be able to comprehend the database structure better when designed 
in the relational model vice a hierarchical or network model. 
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Unlike other database structures, relational databases make ad hoc queries 
possible. Ad hoc means un predicted. Other database models are not structured to answer 
unpredicted questions easily. [Ref. 5: p. 296J The ability to ask ad hoc questions is 
essential for a decision support system. ESAAMS can best benefit from a relational DBMS. 

E. STRUCTURED QUERY LANGUAGE 

The de facto language used in relational data manipulation is SQL (Structured Query 
Language). SQL is a transform-oriented relational language. SQL provides a language to 
transform input into desired output via relations. [Ref. 1 1: p. 321] SQL is not a procedural 
language like ADA, Pascal, or C. It is a fourth-generation (4GL) data access language that 
allows usage between different computers. Until now, transferring data from one computer 
to another proved difficult because each computer had its own data sublanguage. With SQL 
and its simple query/update language, data transfer between micros, minis and mainframes 
can be facilitated with ease. It is employed only to access data from a database and 
manipulate it SQL can be embedded in application programs. 

F. SUMMARY 

The ESAAMS expert system needs a database to provide information. An efficient 
database model is essential for the optimal interaction between the database and the expert 
system. 

Three database models were discussed in this chapter to show the different methods 
for constructing the database schema. The relational database is the model that this thesis 
will use for the design and construction of the ESAAMS Database Management System. 
Several applications that can be used by aviation maintenance managers will be generated to 
show proper functioning of the DBMS. 
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IV. NALDA DATABASES 



A. INTRODUCTION 

The NALDA databases are uniquely qualified to serve as a foundation for essential 
ESAAMS information [Ref. 2: p.49]. Because NALDA is the central repository of data for 
the naval aviation logistics and maintenance community, Burpo ( 1990) concluded to use the 
NALDA databases, sometimes called the NALDA data bank, for the development of 
ESAAMS. This chapter will cover NALDA's program history, databases and their 
contents, and applicability to ESAAMS. 

B. BACKGROUND 

The Naval Aviation Logistics Data Analysis (NALDA) system evolved from the need 
for improved data analysis capabilities to support growth in sophistication and complexity 
of Naval air weapons and associated support systems. Its primary objective is to (support) 
centralized logistics data analysis. [Ref. 14: p.l] It also provides the capability to 
accommodate upline reporting requirements as set forth in the Maintenance Data System 
(MDS) program of the NAMP. The upline reporting is used to transport all maintenance 
data and information from the OMAs, IMAs, and NADEPs to a central repository of data 
for later retrieval. 

The NALDA system is a centralized, integrated and uniform data bank providing 
storage, retrieval and analysis capability. It is configured in a hierarchical database structure 
using the Systems 2000 (S2K), developed by MRI (Intel) Systems Corporation of Austin, 
Texas, in the early 1970s, as its Database Management System. It can be used, in an 
interactive manner, through remote terminals in support of the naval aviation logistics 
community [Ref. 14: p. 1], 
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In the early 1970s, there were hosts of uncoordinated and separate databases and data 
systems in the aviation logistics community. In 1975, the NALDA Automated Data System 
(ADS) Development Plan was formulated. In May of 1976, The Assistant Secretary of the 
Navy (Financial Management) approved the phased development of NALDA. NALDA 
became operational in the early 1980s. Figure 4-1 shows the NALDA 2010 Structure — the 
envisioned NALDA future organization structure. 
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1. Phase One Development: 

NALDA's Phase One goal was the integration of three existing logistics data 
systems: the Analytical Maintenance Program Analysis Support (AMPAS) System, Aircraft 
Maintenance Engineering (AMEN) System, and the Technical Directive Status Accounting 
(TDSA) System. Phase One development also sought the creation of an intensified 
maintenance data analysis capability. [Ref. 15: p.87] NALDA's target user community 
includes: 

• All Navy and Marine Corps Aviation Headquarters 

• Field Activities 

• Type Commanders (TY COMS) 

• Fleet Activities (Intermediate Activities and above) 

A very noticeable omission from the targeted user community are the 
Organizational Maintenance Activities (OMA). Ironically, the originators of the data, at 
present, receive little direct benefit from the NALDA database system. With ESAAMS, 
NALDA will be able to expand its services directly to the organizations that provide the 

bulk of the upline data. NALDA Phase One currently provides the following: 

• A Corporate Aviation Maintenance and Material Management database with on-line 

interactive access Navy-wide; 

• Data analysis capability to perform Reliability Centered Maintenance (RCM); 

• Technical Directive Status Accounting (TDSA); 

• Consolidation of the two original major NA VAIR Information Systems -- AMPAS 

and AMEN. 

2. Phase Two Development: 

Phase Two NALDA objectives are expansions on Phase One and are an 
opportunity to make significant life cycle cost reductions while incorporating needed 
readiness improvements. Development started in early 1985 and is on-going with a 
targeted full deployment date in late 1995. 
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Redundancy exists in the current aviation maintenance data collection system. AV-3M 
data is collected at the various levels of maintenance, processed and sent to NAMSO, 
Chesapeake, VA. At the same time, the same maintenance data is sent to the NALDA 
database system located at ASO, Philadelphia, PA. Realizing this redundancy, the CNO 
has directed NALDA to be the Navy's central upline logistics data system. The program 
management team at NAMO has undertaken the AV-3M/NALDA merger. At this writing, 
the program merger is on-going and is projected for completion in 1997. This merger will 
do much to solve the redundancy problem and also greatly expedite the on-line query 
process. 



Objectives for Phase II include the following: 

• Merger of common AV-3M functions supported by the Naval Sea Logistics Center 

(NSLQ and NALDA to eliminate redundancy; 

• Addition of other logistics data like the Logistics Support Analysis Record (LSAR) 

and Configuration Status Accounting/Serial Number Tracking (CSA/SNT); 

• Consolidation of other logistics information systems (ISs) to follow the OP-51 

Functional Sponsor Plan (FSP) directing NALDA to be the Navy’s central 
upline logistics data system; 

• Improve user-friendliness by the introduction of relational DBMS. 

C. NALDA SUBSYSTEMS AND DATABASES 
The current Phase One NALDA operational system covers a whole spectrum of 
different subsystems and databases to provide system users with information to solve 
problems and make informed decisions. To date there are some 25 databases. Some of the 
more prominent databases are listed below. 

• Fleet Originated Jobs (FOJ) database: the principal repository of reported 

maintenance data from all OMAs, IMAs and Depots. There is one FOJ database 
for each aircraft type/model, plus additional databases for Support Equipment 
(SE), training devices, and other end items identified by a Type Equipment 
Code (TEC). 

• AMPAS system database: to implement and sustain the Phased Maintenance 

Program. This database became the vehicle for providing the analysis 
procedures and techniques needed by Naval Air Systems Command 
Engineering Support Office engineers, analyst managers and type commanders. 
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• AMEN database: developed from the FOJ database to provide in-house logistics 

managers, engineers, and others throughout the logistics community with an 
effective tool to identify and resolve aviation logistics problems. 

• TDSA system database: an automated accounting system designed to store, 

maintain, and disseminate information concerning the status of Technical 
Directives. 

• Depot Originated Jobs (DOJ) database: a database to track maintenance actions 

collected by the Depot Maintenance Data Collection System and originated at the 
depots. 

• Intermediate Maintenance Activity (IMA) Analysis database: contains summary data 

that enables analysis of the production effort at the intermediate level of 
maintenance and at an Aircraft Intermediate Maintenance Department (ALMD) 
for identified items. 

• Present Maintenance Requirements (PMR) database: not yet completed. Will 

contain data describing scheduled maintenance requirements at the O- and I- 
levels. 

• Training database: identical to FOJ except for the different values in the schema 

records. Data in this system pertains to training devices and equipment. 

• Aircraft Engine Maintenance System (AEMS) database: contains information 

derived from the Aircraft Engine Management System (AEMS) data system. 
This database consists of two separate and independent data systems, one 
containing propulsion system data and one containing propulsion system 
module information. The system contains data from the Engine Transaction 
Report (ETR) and calculated data such as turn-around time, operating hours, 
etc. 

• Last Engine Transaction Report (LETR) database: contains information from AEMS. 

• Aircraft/Equipment Summary Reports database: contains summary information 

identical to data reported in AV-3M information reports. 

• Non-Maintenance Job Control Number Supply database: contains information 

identical to AV-3M information reports. 

• Scheduled Removal Component database: contains information from Scheduled 

Removal Component (SRC), Assembly Service Record (ASR), Module Service 
Record (MSR) and Equipment History Forms (EHF) which are collected at the 
Scheduled Removal Component Central repository. 

• Master Index of Repairables database: contains item identification, evolution, 

applications, projected workload, modification and life limited replacement 
requirements information as applicable for each repair item. 

• Individual Component Repair List (ICRL) database: contains data which depicts the 

level of repair capability for each repairable at each Intermediate Maintenance 
Activity. Fully compatible with IMA Analysis database. 

• Code translation database: contains various translation codes; such as Work Unit 

Code (WUC), Type Equipment Code (TEC), and Malfunction Code (MAL), 
utilized in NALDA databases. [Ref. 14: p.2-3] 
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I). DATABASE FOR THE OMA AND ESAAMS -THE FOJ DATABASE 
Burpo (1990) asserted that the most likely database for ESAAMS is the FOJ database. 
This conclusion was based from his interviews with different NALDA users. Research in 
this thesis has uncovered other NALDA databases that are also useful to the OMA 
maintenance expert. Their potential for inclusion into the PC-based expert system will be 
evaluated and discussed fully in the next section. 

The FOJ database stands to be the most logical and usable database for OMA use. 
Chapter D, Section D discussed how data from the OMAs is sent upline using the the AV- 
3M reporting system of the MDS. All this data ends up in the NALDA FOJ database 
schema. All data taken from the VIDS/MAFs, training reports, safety-engineering 
investigations, and depot summaries end up in the FOJ database. Hence, any historical 
maintenance record of an aircraft or an aircraft system can be found in this single NALDA 
database. 

The database itself is enormous and not all data are germane to a maintenance manager. 
The challenge, therefore, is to identify and extract the relevant data from the mainframe 
hierarchical DBMS of NALDA and transfer them to a PC-based relational DBMS for use 
by maintenance planners and ESAAMS. 

E. ANALYSIS OF OTHER NALDA DATABASES 

The feasibility study conducted by Burpo, [Ref. 2], concludes that the FOJ database is 
the most useful for application to ESAAMS because it contains elements necessary to assist 
in the scheduling of maintenance. As pointed out, the NALDA system consists of many 
databases each containing specific data. The question, from a maintained stand point 
must be raised: Do any of these other databases hold information which can be effectively 
used at the O-level? Care must be exercised when examining the contents of a database. 
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One must not conclude just because it contains known useful data for the OMA, that the 
data is also usable for ESA AMS. 

Of the 16 databases listed above, only four contain specific data the authors feel is 
germane to the OMA effort and therefore potentially of value to the ESAAMS database. 
Many of the other databases contain data that is a duplicate of data already included in the 
FOJ database and are not considered. The four useful databases are discussed below. 

1. AMPAS 

The Analytical Maintenance Program Analysis Support (AMPAS) system was 
designed to provide a group of analysis procedures/techniques to NESC 
Engineers/NAVAIR managers through a series of reports to solve day-to-day logistic and 
management problems. The database is massive and encompasses two major subdivisions: 
the Depot Maintenance Data Sub-System (DMDS) and the Maintenance Data Sub-System 
(MDS). The MDS is further divided into three subcategories consisting of the Sub-System 
Capability and Impact Report (SCIR) system, the Maintenance Data Reporting (MDR), and 
3M Flight Data Reporting for aircraft utilization. [Ref. 16: p. 2] 

The AMPAS database contains information from all three levels of maintenance. 
Much of the data from the most recent 1 8 months is identical to data in the FOJ database. In 
addition, it also contains a flight file (aircraft usage), depot and support equipment (SE) 
information. This database also functions as an archive of maintenance information. Data 
for all type of Naval aircraft are available from January of 1980 to the present. This data 
can be readily retrieved for the user without going to the archives. Data on aircraft prior to 
1980 is available by special request. The database is updated monthly but still suffers from 
a 60-90 day delay for processing through the data collection network. 

As mentioned, data contained in the AMPAS database reflects the same data in 
the FOJ database specifically pertaining to the O- Level. The maintenance manager can use 
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this database to retrieve data which is more than 18 months old. For example, trend 
analysis of EMT on a specific system can be conducted to reflect any changes, positive or 
negative, over the life span of a weapon system. 

While very useful historical information is available in the AMPAS system, the 
processes of converting ten years of data, stored in a hierarchical structure, to a relational 
database structure would be time prohibitive. Conversion time not withstanding, physical 
storage space in a PC-based system could not possibly handle this quantity of information 
on a stand-alone basis without an expensive, large capacity hard disk drive upgrade. 
Information required from AMPAS should therefore be accessed through normal query 
methods by certified NALDA users 
2. TDSA 

The Technical Directives Status Account (TDSA) databases contain data 
describing attributes of Naval Air Systems Command (NAVAIR) Technical Directives 
(TD). The primary function is to store, maintain, and disseminate information concerning 
the status of TDs. There is a TDSA database for aircraft (TDAIR), an engine database 
(TDENG), and one for components and support equipment (TDCGS). The databases 
contain detailed inventory records for all TDs reflecting the incorporated/not incorporated 
status of applicable TDs. Historical databases are also maintained for TDs affecting aircraft 
(TDHIS), engines (TDHER) and component/support equipment (TDHCG).fRef. 17: p 1] 

In this research, the chosen aircraft (F/A-18) has seen a multitude of TDs issued 
for update and modification. From the aircraft inception, TD tracking has been one of the 
most time and labor intensive functions of the Maintenance Control staff. Some OMAs 
have even set up separate sub- work centers to manage TDs. The importance of properly 
tracking the incorporation of TDs makes this data extremely important to the safety and 
operation of the aircraft. While every OMA maintains a separate file of source 
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documentation concerning TDs, the authors find this database information important as a 
cross check and management tool. 

TD data is not solely contained in the TDSA databases, the FOJ databases also 
contain data, reported on the VTDS/MAF, concerning the incorporation of TDs. This data 
will be available through the FOJ-derived database, which is the primary focus of this 
research. The TDSA database, much like the AMP AS database, is a historical archive of 
data and contains data beyond the most recent 1 8 months as is the case with the FOJ 
database. 

The O- Level maintenance manager has the same opportunity to conduct trend analysis 
as was the case with the AMPAS database. In this case, the TDSA enables him, or her, to 
look back farther than the most recent 18 months for specific information pertaining to 
technical directives. The NALDA Users Group, upon request, can furnish any batch report 
on any TD incorporation and aircraft/engine configuration. 

3. Present Maintenance Requirements (PMR) Database 

The PMR database will contain data describing scheduled maintenance 
requirements derived from the Maintenance Requirements Cards (MRC) decks [Ref. 18: 
Sec V, p. 40]. MRC decks contain the step-by-step maintenance actions of the PMS 
program. This database will be updated periodically to reflect changes in maintenance 
requirements or errors in the initial requirements recorded in the MRC decks. A database 
containing this information is a major step in the automation of the PMS program. It 
provides the OMA with an on-line system of scheduled maintenance requirement 
information. The maintenance manager can verify his on hand type-aircraft MRC contents 
with the data in the PMR to ensure accuracy. This database, while not available until the 
late 1990s, will be extremely valuable in establishing the ELS A AMS rule base and future 
validation processes since it contains all scheduled maintenance requirements. To date, 
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PMR databases are only available for the F-14 and A-7E MRC decks. As of this writing 
there is no target date mentioned for fleet-wide completion. 

4. Scheduled Removal Component (SRC) Database 

The SRC database contains information archived by part number, including data 
provided by the depots. Each record is included in the database with an indicator 
identifying the most current data for a component by part number and serial number. The 
record includes data concerning installations, removals, overhauls, repairs, and technical 
directive compliance. 

A sub-database to this system is the SRC3M database. This database contains 
data generated from the FOJ history files as recorded in the main SRC database. 

This data set is considered by the authors to be historical and therefore, not of 
immediate use in a day-to-day maintenance environment This system is considered to be 
a valuable data source when researching a specific component for rework or installation 
history. In the case of a component failing at a higher than normal rate, this information 
would be useful to initiate research and trend analysis. The authors believe that this form 
of information would be best served at the I-level, the supporting Supply department or at 
the depot, where most rework is accomplished and inventoried. Value to the OMA is 
perceived as useful, at most, in the case of SRC validation, which is generally considered 
an IMA process and is not considered pertinent to the maintenance scheduling process. 

F. SUMMARY 

The NALDA system is a centralized, integrated and uniform data bank providing 
storage, retrieval and analysis capability that can be used in an interactive manner, through 
remote terminals in support of Naval Aviation Logistics community. The system provides 
a blanket of coverage throughout the field of aviation maintenance and is one of the main 
repositories for all data generated at the three levels of maintenance. 
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A very noticeable omission from the target user community for NALDA are the 
Organizational Maintenance Activities (OMAs). The NALDA databases are uniquely 
qualified to serve as the foundation for ESAAMS in the OMA. With ESAAMS, NALDA 
will be able to expand its services directly to the organizations that provide the bulk of the 
upline data. 

The current Phase One NALDA operational system covers a whole spectrum of 
different subsystems and databases to provide system users with information to solve 
problems and make informed decisions. Burpo (1990) asserted that the most likely 
database for ESAAMS is the FOJ database. The FOJ database stands to be the most logical 
and usable database for OMA use since it is one of the main repositories for AV-3M upline 
data. Four additional databases from the NALDA system contain specific data the authors 
feel are germane to the OMA effort and therefore may provide some utility for ESAAMS. 
They are: AMPAS, TDSA, PMR, and SRC databases. 

While no amount of data will help the maintenance program if it is not processed into 

i 

information and used, this research has found that there is a wealth of data available, which 
is applicable to O-level maintenance planning. The only investment necessary is the 
training of a qualified user to extract data from the current NALDA system. ESAAMS will 
greatly expedite this process through on-line access to pertinent NALDA data when it is 
required . 

The NALDA database is not the only source of data available to the OMA user. Two 
non-NALDA programs currently hold an important link to the success of ESAAMS. They 
will be the subject of the next chapter. 
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V. NON-NALDA DATABASES 



A. INTRODUCTION 

In this chapter we will examine other databases available to the maintenance expert. 
While these systems are not currently planned for linkage to this project’s database, the 
authors feel that the future will see close interaction between these systems and an expert 
system such as ESAAMS. We have chosen two systems which are in operation but are not 
currently directly linked to the NALDA system. The Enhanced Comprehensive Asset 
Management System (ECAJMS) and The Naval Aviation Logistics Command Management 
Information System (NALCOMIS) will be examined. A brief background of each system 
will be provided followed by future uses for each. 

In this thesis we are focusing our attention on database construction of a generic 
DBMS from NALDA databases. As previously mentioned, research for this project 
involved the F/A- 18 Hornet aircraft and Strike Fighter Squadron OM As. The Hornet 
weapons system was developed to include several state-of-the-art subsystems to assist in 
the accomplishment of aircraft maintenance. One of these subsystems is ECAMS. 
ECAMS is unique to the F/A- 18 aircraft 

B. THE ENHANCED COMPREHENSIVE ASSET MANAGEMENT 
SYSTEM 

ECAMS is an on-line, interactive, computerized monitoring and data management 
system which is, as stated in Ref. 19 (p 1-1): 

"...designed to support the Reliability Centered Maintenance/On-Condition 
Maintenance philosophy for the F/A- 18 aircraft and F404-GE-400 turbofan engine. 
Reliability Centered Maintenance (RCM) is maintenance which enables equipment to 
perform its task with a specific probability of success at the lowest possible total cost 
for system operation and support of its life cycle. On-Condition Maintenance (OCM) 
is based on replacement of aircraft and engine components and the performance of 
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scheduled maintenance only when necessary to preclude operational failures or 
degradation of weapon system performance." 

The EC AMS system is intended to facilitate efficient, timely, and cost effective aircraft 
maintenance while ensuring high levels of aircraft reliability [Ref. 20: WP 002 00 p. 4 ]. 

1. The F/A-18 Hornet Aircraft 

To fully understand the EC AMS system, a brief description of the major weapon 
system must be made. The F/A-18 Hornet aircraft was designed to fulfill both the light 
attack and fighter/intercept missions in a single weapon system base, as demanded by 
Naval Aviation. The aircraft was procured as a replacement for the aging A-7 Corsair II 
attack aircraft and the F-4 Phantom II fighter aircraft McDonnell Aircraft (prime 
contractor) and General Electric (ga^ turbine engine division) teamed to produce this twin 
engine "strike-fighter," which entered the fleet in the early 1980s. 

The engine selected for the F/A-18 is the General Electric (GE) F-404 turbofan 
engine. The F-404 reflects the current state-of-the-art modular engine design vice 
conventional designs in which the engine is a complete end item, which can only be broken 
down into component parts. Modular design divides the engine into separate components 
or modules which can be removed and repaired separately from the end item. This affords 
the intermediate maintenance activity the option of removing the defective module(s), 
replacing it (them) with RFI or ready for issue module(s), then repairing the defective 
module separately from the main engine assembly. This expedites engine repair turn- 
around time and returns critically needed assets to the supply inventory. Earlier called the 
"augmented turbofan," the engine is also installed in the F-l 17A Stealth Fighter and several 
retrofit types of aircraft around the world. 
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Unique to the F/A-18 is the process of accounting for the life of component 
parts 2 . Instead of the traditional flight hour accounting used to determine part life limits in 
most naval aircraft, the Hornet system measures the useful life of component parts, 
especially critical engine components, as a function of the environment in which the part is 
used. For example, the severity of engine internal operating environment is measured in 
terms of power cycles and resultant internal engine temperature and speed variations. 
Several parameters, called Life Used Indices (LUI), have been developed to measure 
operating severity and are automatically recorded by installed systems. [Ref. 19: p. 1-4] 

Performance data is recorded on the aircraft by the Maintenance Status Display 
and Recording System (MSDRS) T pe Transport Magazine (TTM), for F/A-18A/B aircraft 
and Flight Indicator Recording and Monitoring System (FIRAMS) Memory Unit (MU) for 
F/A-l 8C/D aircraft. Engine and airframe operational status are continuously monitored by 
MSDRS or FIRAMS for unit failures. If failure is detected, the mission computer will 
activate the TTM/MU to record significant maintenance data and selected tactical/inflight 
information. This data can be used by maintenance experts in the OMA to troubleshoot and 
fault isolate applicable systems. [Ref. 19: p. 1-1] 

2. The ECAMS Data Processing System 

Upon completion of a flight, data must be downloaded from the aircraft before it 
is accessible to the maintenance crew. The TTM/MU is removed from the aircraft and 
brought to the ECAMS Ground Station, sometimes referred to as the ECAMS Processing 
Unit (EPU), where the data is extracted. The EPU enables the processing and storage of 
the performance data. During the process, the data is augmented with other information 
pertinent to the flight data from the aircraft. This data is manually entered by maintenance 



The Navy us currently developing systems similar to ECAMS in the F-14 A+/D program. Other EC A MS- 
like systems will be used in future aircraft development. 
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control personnel and include selected elements from the VIDS/MAF and other control 
documents relating to the flight. The EPU supports organizational maintenance 
requirements in the following ways: maintenance fault isolation of selected avionic and 
non -avionic systems, F-404 engine exceedances, engine performance data and selected life 
limited components usage data. 

Data is transmitted upline from the EPU via a telecommunications network, 
which links the organizational sites, intermediate sites, and the Parts life Tracking System 
(PLTS) Central Data Base (CDB) using the NALDA Interface Computer (NIC). OMA data 
is transmitted daily to the IMA for networking to the CDB. Shipboard data is forwarded to 
NALDA via PLTS tapes. 

3. OMA Reports 

a. Structural Appraisal of Fatigue Effects (SAFE) Program 

The F/A-18 Structural Life Tracking system represents the Navy's first 
advanced development effort to access an entire fleet's airframe fatigue life. [Ref. 19: p. 1- 
4] Squadrons generate fatigue data through the EPU. Data is compiled and reported back 
to the OMAs as a SAFE fatigue report published quarterly by NADC. This information is 
available to the OMA to track fatigue life limit and inflight loading of all assigned airframes. 

b. Inflight Engine Condition Monitoring System (IECMS) 

Reports 

IECMS Reports are engine status reports used to track engine life cycle 
usage, and to record engine event data. An engine event is an occurrence of any of the 
following conditions on either engine: overspeed, abnormal inlet temperature, high Exhaust 
Gas Temperature (EGT), flameout, or abnormal oil pressure. [Ref. 20: WP 004 00 p. 2] 
Use of the reports are valuable in the diagnosis of engine problems which could ultimately 
result in an engine change. 
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c. Engine PLTS Reports 

The F-404 engine contains forty-five (45) components, which are tracked in 
the PLTS. Twenty-four (24) of these components are life limited parts. It is imperative 
that modules and other major assemblies are tracked to follow the life limited parts within 
these assemblies.[Ref. 20: WP 005 00 p. 2] Prior to extended deployments at the O- level, 
knowledge of engine components life limits becomes a major planning tool to access engine 
needs during the deployment. This information can eliminate high time engine changes 
during deployment and aid in the determination of stock levels in ship's supply. 

d. Avionics Built-in-Test (BIT) Recording Reports 

Avionics BIT recording reports are systems status reports that can be used 
to determine system operation and provide fault analysis. BIT reports can provide 
information isolating failure information down to the subassembly or Shop Removable 
Assembly (SRA). An SRA is a system component, commonly a circuit card or small 
component, within a major system component or Weapon Removable Assembly (WRA). 
The components are nomally changed at the IMA. 

C. NALCOMIS 

The Naval Aviation Logistics Command Management Information System 
(NALCOMIS) manages, tracks, and reports on aircraft maintenance and material 
management requirements throughout the Navy and Marine Corps. The system is defined 
as a fully integrated computer system that provides local managers with a tool, which will 
aid them in their day-to-day management decisions affecting their assigned aircraft and 
equipment. [Ref. 21: p. 2-1] 

1. Background 

The AV-3M system was developed in 1964 to automate data collection of 3M 
source data to upline activities. Summary reports were also provided back to squadron 
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activities on a monthly basis. [Ref. 21: p. 2-1] The AV-3M system provided effective 
validation of source documentation and upline reporting but did not provide this 
information to reporting activities in a timely manner. As a result of this shortcoming, the 
NALCOMIS concept was bom. 

The NALCOMIS Mission Element Need Statement (MENS) of 1984 identified 
three major deficiencies within the OMAs, IMAs, and the Supply Support Centers (SSC). 
These deficiencies were: lack of real-time management information, a difficult data 
collection process, and inadequate up-line information reporting. [Ref. 22: p. 1] 

The principal objective of NALCOMIS is to automate the NAMP business 
functions throughout Navy and Marine Corps aviation maintenance activities, and to 
implement a standardized management system that will have a measurable, positive impact 
on aircraft weapon system readiness. 

2. Three Phases of NALCOMIS 

Introduced in three phases, the current implementation plan reflects complete site 
implementation by the year 1997. 

a. Phase I 

Phase I, implemented at the IMA level, provided a first look at key-entered 
demand and status data and reduction of the common paper traffic associated with repair 
functions. Called NRMM for NALCOMIS Repairables Management Module, the system 
provided limited functionality and served as an intermediate step toward implementation of 
Phase II. Information was provided on demand (screen-driven) and through batch reports 
reflecting component status within the repair process. 

b. Phase II 

Phase II implements full functionality of NALCOMIS operations at the IMA 
and SCC. Unlike NRMM, Phase II makes provision for on-line source data 
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entry/validation and local up-line reporting of AV-3M data through batch reports and 
magnetic media, interactive interfacing through supply information systems, and 
management information to the IMA in areas of personnel management, technical 
publications, equipment, and configuration control. [Ref. 22: p. 3] 
c. Phase III 

Phase III, or NALCOMIS OMA, is currently being implemented at chosen 
sites throughout Navy and Marine Corps OMA activities. This implementation represents 
the first release of Phase III technology and will be evaluated at these alpha sites prior to 
complete implementation in OMAs fleet-wide. 

Phase III provides full functionality of NALCOMIS at the OMA. The 
systems designed to provide on-line processing of all maintenance, flight, and supply 
information which supports aircraft mission capability. The on-line processing features 
support immediate intra- and inter- organizational communication of maintenance action 
initiation, approval, priority assignment, work status, and material requirements 
information. [Ref. 21: p. 3-2] 

Data loaded into the system and electronic interfaces with other automated 
systems allows aviation maintenance managers to monitor and analyze logistics, 
supportability, readiness, flight safety, configuration management, and other critical 
parameters. This information, when applied to NAMP principles, forms the foundation for 
a sound maintenance program. 

The system, when fully implemented, will consist of nine subsystems 

supported by the NALCOMIS OMA database. (See Figure 5-1 ) The system includes: 

1. Database Administration Subsystem --provides the baseline data for the squadron, 

system security, and data tables. 

2. Flight Subsystem -collects and processes flight related data. 

3. Maintenance Subsystem —collects and processes maintenance-related data. 
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4. Logs and Records Subsystem —provides the ability to establish and maintain 

configuration profiles on aircraft, engines, modules, and components assigned 
to the squadron. 

5. Personnel Subsystem —automates many of the administrative functions associated 

with personnel management including the maintenance of military manning 
authorization and manning information. 

6. Data Analysis Subsystem —provides the squadron's AV-3M analyst the ability to 

review and correct each flight and maintenance record prior to submission into 
the AV-3M system 

7. Technical Publications Subsystem —provides the ability to manage the squadron's 

assigned aeronautical technical publications. 

8. Reports Subsystem —provides the ability for a squadron to select and execute 

NALCOMIS OMA reports. 

9. System Administration Utility —provides the ability to the squadron's NALCOMIS 

system administrator to maintain the squadrons NALCOMIS system. 




Figure 5-1. NALCOMIS Phase III Subsystems 
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Ref. 22 lists the following qualitative benefits of Phase III: 

• Improved Management Information to Local Squadron Managers 

• Improved Aircraft Material Readiness 

• Improved Accuracy of Aircraft/Engine Configuration 

• Improved Maintenance through Automated Tracking of Aircraft and Support 

Equipment Scheduled Maintenance 

• Improved Management Information through Timely Automated Data From 

Squadrons Detachments with PC-Based NALCOMIS System 

• Improved Standard Asset Management at OMA 

• Improved Data Collection and Accuracy 

• Improved Pilot/Aircrew Flight Data Reporting/Record keeping 

• Elimination of 3M Source Document Key Entry at Supporting DSF 

• Improved Standardization of Maintenance Administration 

I). SUMMARY 

Data management in the OMA is of paramount importance to the success of the 
maintenance program. Data is collected during the flight and throughout the maintenance 
process by various methods and transferred into the AV-3M system or similar databases. 
Currently there are limited ways to retrieve this data for use at the O-level. 

The Enhanced Comprehensive Asset Management System (ECAMS) was developed 
as an on-line, interactive, computerized monitoring and data management system in support 
of the F/A-18 Hornet aircraft The F/A-18 concept, in concert with ECAMS, incorporated 
a new way of measuring the useful life of component parts using parameters called Life 
Used Indices (LUIs). The LUI concept takes into consideration more of the flight 
characteristic variables than do conventional flight hour measurement methods used on 
most naval aircraft. ECAMS provides maintenance experts real-time data to evaluate, 
troubleshoot, and fault isolate conditions occurring outside acceptable parameters. 
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The Naval Aviation Logistics Command Management Information System 
(NALCOMIS) is a CNO-backed initiative to provide an automated method of providing 
AV-3M information back to the reporting activities in a timely manner. Three deficiencies 
were noted in the NALCOMIS Mission Elements Need Statement (MENS) of 1984. They 
were: lack of real-time management information, difficult data collection processes, and 
inadequate upline information reporting. NALCOMIS addresses these issues and 
automates NAMP business functions throughout the Navy and Marine Corps. 

NALCOMIS was implemented in three stages with current focus on the OMA (Phase 
m). Phase III provides full functionality of NALCOMIS to the OMA and consists of nine 
subsystems. Each of the subsystems provides a different measure of functionality to the 
OMA. When fully implemented the system should provide improved management 
information to OMA experts including real-time information retrieval capability. 

The future of automated data management should fmd EC AMS, or a form thereof, and 
NALCOMIS providing necessary information in a timely and accurate manner to the 
maintenance expert. Incorporation of this technology, with improved decision making 
tools, hold the key to improved aircraft material readiness and efficient use of funding. 
Conclusions and recommendations for the future of these two systems will be discussed in 
later chapters. 
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VI. USER INPUT 



A. INTRODUCTION 

The idea of developing an expert system advisor for the aviation maintenance 
community was introduced by the authors to U.S. Navy and U.S. Marine Corps aviation 
maintenance personnel at NAS Lemoore, CA. The idea was presented to both senior 
enlisted and experienced aviation maintenance officers. The presentation and interviews 
were conducted in two fleet aviation squadrons, VFA-25 and VFA-1 13; and then with the 
expens on the staff of the Naval Aviation Maintenance Training Group Detachment 
(NAMTRAGRUDET), Lemoore. 

Interviews in the two fleet squadrons were conducted on a one-to-one basis with key 
officer personnel in the maintenance department The authors found the informal interview 
process allowed "uninhibited" information flow in which the interviewees felt free to 
express opinions and make suggestions about the NALDA system and the ESAAMS 
concept in general. 

Interviews at NAMTRAGRUDET were conducted in an open forum format. The main 
group consisted of 20 senior enlisted maintenance experts from various type-aircraft 
backgrounds. The concept was briefly introduced and explained by the authors followed by 
an informal question/answer period in which opinions and views of NALDA and ESAAMS 
were discussed. The authors were available for the remainder of the day for one-on-one 
interviews with selected personnel. 

Reactions to the concept were varied, ranging from total acceptance to total pessimism 
and doubt. This was expected. This form of research was chosen to facilitate a bottom-up 
approach to pool the experts' knowledge vice a top-down, closed environment, model. 
During the interviews, it was noted by most of the personnel that this strategy was the only 
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way to successfully produce the system. 



This kind of end-user involvement is what most information systems developers 
encourage when developing new IS software. Involving the user is a logical and important 
step in the analysis and development of any information system. In the final analysis, if 
users cannot understand the system, it won’t be utilized or in some cases, the user will 
employ other means to avoid system utilization. 

As mentioned above, this form of information gathering is not scientific by nature and 
is from a limited sample. But it does offer some insight to the views of maintenance 
personnel assigned within the F/A- 18 community. The opinions expressed by the personnel 
interviewed do not necessarily reflect either the F/A- 18 or the Navy-wide aviation 
maintenance community's views of the subject They do, however, serve as important 
information for the design of a maintenance related DBMS. For it is user input which will 
make this or any system a viable decision making tool. 

The results of the interviews and comments about the use of the NALDA database for 
ESA AMS are summarized below. 

B. INTERVIEW INFORMATION 
1. Scheduled Maintenance 

As pointed out by McCutcheon |Ref. 23: p.33], data in the NALDA database 
routinely suffers from a 60 to 90 day lag. This time lag limits usefulness of the data. One 
possible use of the NALDA database in its current configuration involves scheduled 
maintenance. Using historical records of elapsed maintenance times, scheduling of required 
aircraft inspections can be prioritized. 

Figure 6-1 shows the proposed data flow after the AV-3M/NALDA merger, 
currently in work. One of the obvious benefits from this merger will be much more rapid 
transmission of data to the NALDA database and reduction of the time lag. Some expected 
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estimates, post-merger, put the future time lag at no more the 20 to 30 days. The merger 
and implementation of NALCOM1S OMA greatly expedites the MDS cycle virtually 
eliminating any retrieval or accuracy problems due to a time lag. 

Scheduled maintenance was one of the common areas of focus throughout the 
interviews. A majority of the experts interviewed agreed that a NALDA -derived system for 
scheduled maintenance is feasible. 




Figure 6-1. Proposed A V-3M Data Flow 
Another closely related area involves the construction of the Monthly Maintenance 
Plan (MMP). Scheduled inspections are required at various times in the maintenance cycle 
of every aircraft. These inspections are required either by the passage of time or by the 
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accumulation of flight hours. 3 The maintenance planner must compile these requirements 
and schedule them into a systematic format to accomplish inspections as required. 
Historical information can assist in planning when to accomplish a specific inspection within 
the "window," or acceptable time frame, of the inspection. Once again, elapsed maintenance 
time is an important variable. Using EMT the maintenance planner gains insight into how 
many man hours a typical maintenance procedure may consume. When dealing with 
scheduled maintenance, workloads can be prioritized to conform to available maintenance 
time, i.e., per shift or work day. For example, if several aircraft require scheduled 
maintenance, and there is a requirement for a large number of aircraft to be mission capable 
the next day, the maintenance planner can draw EMT information from historical files to 
prioritize tasks to optimize aircraft availability for the next day. In other words, perform 
those scheduled maintenance tasks which provide the maximum number of "up" aircraft 

The FOJ database contains this data. Automation of some of the squadron MMP 
can be performed by a DBMS on a stand-alone PC using this data at the OMA. 

2. Unscheduled Maintenance 

Unscheduled maintenance is a dynamic process requiring access to information, 
which is as current as possible. The NALDA time lag becomes a limiting factor in this 
environment. Application of data in this situation is limited to trend analysis usage. Our 
interviews also revealed other information needs of the experts. To a person, a common 
theme became obvious: What the maintenance controller needs most is a tool, with 
instantaneous access to current data, to make the correct decisions in this dynamic 
environment. The current NALDA structure cannot support this need nor was it ever 



3 In mos( aircraft, flight hours are used to track the relative age and use of certain critical parts. As 
mentioned, the F/A-18 aircraft system uses LUIs to track the life, and to determine when certain inspections 
are required, for a number of critical parts in the PLTS program. 
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designed to. Real time computing is a necessity in the aviation maintenance environment. 
The combination of N A IX) A database use and NALCOMIS OMA should provide the access 
necessary to enable a real time or near real time environment. 

3. Real Time Computing 

If on-line and real time computing is available in the maintenance environment, 
the maintenance manager can improve decision making capability quantifiably. The speed in 
which the environment changes becomes a limiting factor. Automation can put the right 
information in the right place at the right time, and speed. Unfortunately, the present 
NALDA database system alone cannot support this type of real time access. To accomplish 
this desired product, linkage to a MiS, like NALCOMIS, is necessary. 

4. NALDA Data Use 

As pointed out by McCutcheon [Ref. 23: pp. 46-48 ], NALDA data does not 
enjoy wide usage in the OMA. For various reasons, whether they are unaware of data 
existence or it is just used for historical data retrieval, OMA managers don't regularly use 
NALDA data. The AV-3M monthly summary does receive limited use, but rarely are real- 
time decisions made using this form of data. 

The experts also questioned the necessity and application of NALDA data. Their 
views seemed to be consistent with those found in McCutcheon's (1989) interviews. 

5. NALDA Accuracy 

Another area of concern expressed by the experts was the accuracy of NALDA 
data. It is a widely known but little discussed fact that a squadron is graded on readiness 
numbers obtained from the data submitted into the system. The AV-3M system was never 
designed for this purpose. Before data is released into "the system" it is thoroughly 
screened, "scrubbed,” for any bit of information which could be detrimental to the 
squadron’s chance in competing for the various awards given on an annual basis. 
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Information is also "looked at" during inspections and is used as a grading criterion when 
trying to separate the "best" squadron from the others, in some higher commands. 

The accuracy of the data is therefore questionable in most maintained minds. 
Burpo [Ref. 2: pp. 37-41] poses the question of data accuracy and concludes that a "data 
fudging" occurs on a frequent basis. Burpo continues, citing several additional reasons for 
the inaccuracy of NALDA data. The authors and the experts interviewed agree, from their 
experience with fleet inputs, that there is a "fudge factor" used especially in the Subsystem 
Capability Impact Reporting (SCIR) system. 

6. What about NALCOMIS? 

NALCOMIS Phase II is gaining rapid acceptance from the users interviewed. 
Much of this stems from the system’s capabilities to provide on-line and almost real time 
computing. 

NALCOMIS Phase III, or NALCOMIS OMA, can provide the on-line real time 
computing needed by O-level managers. Data can be provided upline and downline from 
the network with connections to supply databases and other maintenance information 
databases. NALCOMIS OMA will also be the AV-3M reporting vehicle and, thus, will 
contain all squadron VTDS/MAF and Naval Flight Record Subsystem (NAVFLIRS) input, 
the very sources of data required by the maintenance manager. 

7. User-Friendly System 

Any information system that is to be introduced must be designed with the KISS 4 
principle in mind. This statement was echoed by all senior enlisted personnel interviewed. 
There is no need to expend energy developing a system people find too complicated to 
operate and, therefore, won’t use! 



4 KISS: Military slang for Keep It Simple, Stupid. 
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To satisfy this need, complete interaction with the user during the design phase is 
essential. They alone are the people who will use and benefit from the IS. 

8. Other Findings 

The experts were generally in favor of a system designed to help the maintenance 

program operate more smoothly. Other ideas include: 

• Daily schedule of events including maintenance priorities, personnel manning 

requirements, non -maintenance related events, etc. 

• Cannibalization tracking 

• Part tracking through the repair system (would require link to I-level) 

• Link to the supply system part expeditor. Would provide continuous update of part 

availability. 

• Scheduled Removal Components (SRC) scheduling, (requires real time link) 

• Location specific parts/equipment requirements. Would allow squadrons to obtain 

information on part/equipment requirements for geographical-specific 
detachments/deployments. (i.e., cold weather vs. warm weather operations) 

• Phase maintenance kit tracking 

• Special inspection tracking (i.e., hard landings, engine over speed/over temp, etc.) 

• Inventory tracking. Aircraft, engine accessories, system integrity, classified 

communications equipment, and other reportable equipment 

The information presented above indicates a deep rooted interest by some fleet 
experts for a better information retrieval and management system. NALCOMIS OMA will 
provide the capability for many of the experts needs. No single system, one which can 
accomplish aH maintenance management needs, is planned for the foreseeable future. 

C. SUMMARY 

The intended users for ESAAMS were very direct and forthright with their comments 
on the proposed system. There were three immediate uses that most could see for the 
NALDA database, namely, scheduled maintenance, failure rate information and trend 
analysis. While this was a common thread, it was not the primary desire for what they 
really want or expect from a DBMS or expert system. On-line and real time computing are 
what is desired and needed. Users want instantaneous access to current data to help 
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manage the demands of a dynamic environment. The authors agree that this is the direction 
of the future. The last chapters will deal with a prototype design of an ESAAMS DBMS. 
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VII. DBMS PROTOTYPE DESIGN 



A. INTRODUCTION 

This chapter will discuss the design process of the ESA AMS Database Management 
System. As mentioned in Chapter III, a DBMS stores, retrieves, and updates data. For the 
ESA AMS DBMS, the data will come from the NALDA FOJ database which is determined 
by the authors as the most useful database for an OMA maintenance manager. The FOJ 
database contains a large volume of data that it can easily overload the capacity of a 200 
megabyte PC hard disk drive. Hence, the prototype database design for this thesis will only 
consider data applicable to a single aviation squadron. With an evolutionary prototype 
ESAAMS DBMS in mind, careful consideration into the modularity of the database design 
is undertaken. Starting small with a single squadron, the prototype database design can be 
expanded to a larger organization like an Air Wing or a Fleet Command. The only limitation 
that the authors see right now is the micro-computer hard disk drive capacity. The data 
extracted from the NALDA database for this thesis is for VFA-25, an F/A-18 squadron 
based at NAS Lemoore. CA. 

Conversion from a hierarchical database model to a relational database model is needed 
in order to take advantage of the powerful 4th generation language (4GL), SQL, for use by 
squadron personnel. As mentioned in Chapter III, use of SQL makes ad hoc queries of the 
database possible and, therefore, provides a wide range of flexibility for the maintenance 
manager to manipulate the database for decision support. 

The DBMS design process will cover four phases: definition, requirement, evaluation, 
and design. Implementation of the prototype design, using ORACLE® RDBMS software 
will not be covered in this thesis. A separate User’s Manual, software application package, 
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and demonstration database will be available in April, 1992 through the thesis advisor at 
Naval Postgraduate School, Monterey, CA. 

B. DEFINITION PHASE 

The ultimate goal of this continuing research on ESAAMS is to develop an expert 
system advisor for the OMA maintenance manager. It is mentioned in Chapter III that a 
knowledge base that accesses a database containing historical data, for a particular model 
aircraft, is an integral part of this expert system. This database contains all domain facts that 
the expert system can use. The creation of a DBMS, as a module of ESAAMS, will enable 
the maintenance managers to view data, analyze trends, print reports and perform limited 
what-if decision queries. 

1. Scope 

Optimally, use of the entire NALDA database would have been needed in order 
to cover all aspects of maintenance in naval aviation and provide the maintenance manager 
with the plethora of information he requires. However, the NALDA FOJ database can be 
sufficient to perform scheduling, trending, and analyzing. Chapter IV covers the NALDA 
databases and the contents of the FOJ database. 

Extraction of data from the hierarchical NALDA FOJ database into the relational 
database of ESAAMS can be performed by pulling out attributes from the FOJ schema. 
These attributes are grouped together to form the entities or objects that will make the 
relational database. In other words, the extracted attributes will be constructed into a flat 
spreadsheet-like table, then transferred to the corresponding relational table of the 
ESAAMS DBMS. Extracted data from NALDA will be in ASCII format and transferred in 
batch via the floppy disk medium. The ORACLE® SQL Loader utility tool will be used for 
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the data transfer. This method of constructing the relational database from a hierarchical 
database is the simplest and most feasible way of transformation without creating numerous 
anomalies in the system. Current field research is still underway in the transformation of 
entire hierarchical databases into relational databases [Ref. 24]. 

2. Feasibility 

The method of extracting data from a hierarchical database by creating flat file 
tables and then transforming into a relational database is feasible. The process itself is 
simple but careful consideration into the design of the relational tables is paramount in order 
to avoid anomalies in the resulting r lational database. [Ref. 24] 



C. REQUIREMENTS PHASE 

Potential users from VFA-25 and Senior Enlisted Personnel from 
NAMTRAGRUDET, NAS Lemoore, CA were interviewed. Chapter VI contains some of 
their maintenance management needs that can be fulfilled by this prototype DBMS. The 
NALCOMIS OMA, when fully operational, will be a better source of data for maintenance 
management because of its real time capability. With the 60 to 90 day time lag that is 
inherent in the NALDA data, all potential users conclusively stated that the most probable 
use for the extracted data is for historical-type knowledge. Potential applications can 
include: 

• Historical Failure Report - this report records historical failure rate of systems 
identified by Work Unit Codes. For a selected WUC, the maintenance manager 
can get an idea of the failure rates of specific systems or subsystems 
historically. This is a very important application for ESAAMS. For this thesis, 
only the F/A-18 aircraft for VFA-25 will be covered. As the database is 
expanded, other aircraft type and squadrons can be queried. 
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• Average Elapsed Maintenance Time Report - this report shows the average 

elapsed maintenance times (EMT) of systems or subsystems identified by WUC 
for a specific action taken (AT) code. For example, an action taken code of "R", 
which means remove and replace, is used when a component is removed due to 
a suspected malfunction and the same or like component is reinstalled. This 
gives a maintenance manager an idea of how much time to allocate for a specific 
maintenance action. This information can be very valuable for ESAAMS. 

• High Manhour Consumer Report - this report can aid the maintenance manager 

in identifying problem areas in aircraft maintenance as evidenced by manhour 
consumption. This report can be queried according to aircraft Bureau Number 
(BUNO), aircraft system or subsystem as identified by WUC. Top manhour 
consumers can be identified immediately by aircraft identification then by 
system WUCs and subsystem WUCs. Analysis of this report can show 
maintenance managers of potential problems to specific aircraft or 
sy stem s/sub sy stems. 



A very limited application can be supported by this stand-alone database because of the 
time lag. Yet, for applications that are not considered dynamic, that is, not requiring real 
time data, the DBMS can be used. 

Figure 7-1 shows the data flow diagram of the prototype DBMS. Updating of data is 
only done in batch mode on a monthly frequency, which corresponds with the update of 
data in the mainframe NALDA database. Once data has been transferred from the NALDA 
database to the ESAAMS relational database, applications can be generated by using the 
SQL language for ad-hoc queries or the programmed reports. 



1. Database Objects 

Five objects are designed for this prototype database. An object is a named 
collection of properties that sufficiently describes an entity in the user's work environment 
[Ref. 11: p. 90]. Appendix A shows the construction of these five objects. Object 
diagrams summarize the knowledge of the objects and present them visually and 
unambiguously [Ref. 11: p.9l]. Appendix C contains object specifications and domain 
definition for the database. 
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Figure 7-1. Dataflow Diagram 
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a. Maintenance Action 



This object describes data which is primarily documented in the completed 
VIDS/MAF. It contains attributes like elapsed maintenance time (EMT), action taken code, 
work unit code (WUC), etc. There are a total of 18 properties in Maintenance_Action. 
Fifteen are non-object properties and three are object properties. An object property is a 
characteristic of the entity that is another object [Ref. 1 1: p. 91]. 

b. End_Item 

End_Item contains type equipment code (TEC) as reported in record type 
"A” of the VIDS/MAF, record type "7B" or record type "79." Aircraft end item and 
program (parts) end items are both contained in this object. There are six End-Item 
properties, four non-object and two object properties. 

c. Equipment _Summary 

Equipment_Summarv contains availability and utilization data for 
aircraft and training devices as reported on record type "79." Mission capability hours 
whether FMC, PMC, or NMC per aircraft are contained in this object. Total flight hours 
and number of flights are also included here. Equipment-Summary contains 14 
properties with 1 3 non-object properties and one object property. 

d. Incorporated _TD 

Incorporated.!!) contains data pertinent to an individual technical 
directive incorporation as reported on record type "F" of the VIDS/MAF. Technical 
Directives are always used during any maintenance evolution because they contain the latest 
technical changes that must be followed before any given part or equipment is worked on 
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or operated.. There are eight properties for Incorporated_TD with seven non-object and 
one object property. 

e. Job_lD 

Job_ID contains the job control number (JCN) that OMAs assign to their 
maintenance action. This is used to track maintenance actions and identifies the organization 
performing the maintenance. Job_II) contains six non-object properties and one object 
property. 

Appendix B shows the Object diagrams and Appendix C contains Object 
specifications and domain definitions for this database. Object diagrams summarize the 
knowledge of the objects and present them visually and unambiguously [Ref. 1 1: p.91]. 

2. Methodology 

The Objects formulated for this database are output-driven (i.e., derived from 
intended applications). The authors' interview with domain "experts" resulted in several 
applications that can be developed by the database. Although these applications are limited 
in scope, as far as optimality of usage in aviation maintenance, they show that the DBMS 
can be used for the ESA AMS system. Information derived from the VIDS/MAF is most 
relevant for any maintenance manager, therefore, the formulation of these objects 
concentrated on the data recorded from the VIDS/MAF. 

D. EVALUATION 

The evaluation phase of any system development consists of three tasks. First, 
alternative application system architectures are identified. Second, the feasibility of the 
application is reassessed now that the requirements are known in more detail and the basic 
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alternative solutions have been specified. And third, all user requirements are reevaluated 
within the context of each possible solution. [Ref. 1 1: p. 78] 

More comments on this section will be provided in the concluding chapter of this 
thesis. 

E. DESIGN 

The design phase includes the logical database design and the applications design. A 
graphical representation is presented in Appendix B. 

1. Logical Database Design 

a. Relationship between parent End_Item and siblings 

Maintenance _Acti on and Equipment JSummary 

The End_Item, uniquely identified by TEC (Type Equipment Code) and 
BUNO, may have a number of Maintenance_Action and Equipment_Summary. 
End_Item has a one-to-many (1:N) optional relationship with either 
Maintenance_Actions and Equipment_Summary objects. TEC and BUNO are 
foreign keys to both Maintenance_Action and Equipment_Summarv. JCN and WC 
are the primary keys for Maintenance_Action, while BUNO and YYMM-ES are the 
primary keys for Equipment_Summary. 

b. Relationship between parent Maintenance _Action and sibling 
Incorporated_TD 

The Maintenance_Action, uniquely identified by JCN and WC, has a 
one-to-one and optional relationship with Incorporated_TD. But the reverse is a 
mandatory relationship. In other words, a given Maintenance_Action does not 
necessarily have to have an Incorporated_TD but for each occurrence of an 
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Incorporated_TD a Maintenance_Action must be present. JCN and WC are foreign keys 
to Incorporated..!!) with TD_Num and JCN, as primary keys. 

c. Relationship between parent Job_ID and sibling 

Maintenance _Action 

Maintenance_Action and Job_ID are related one-to-many (1:N). A 
Maintenance_Action must have (mandatory) one Job_ID but a Job_ID is only 
optionally related to Maintenance_Action. WUC and WC are Job_ID's primary keys. 
Maintenance_Action will contain WUC and WC as foreign keys. 

There is no relationship between Maintenance_Action and 
Equipment_Summary. 

2. Application Design 

The application output (i.e., reports and forms) will be developed using 
ORACLE® RDBMS Version 6 software. Use of ORACLE® is necessary because 
NEXPERT OBJECT®, the target expert shell software for ESAAMS development, 
interacts with the ORACLE® RDBMS. 

User-friendliness of the system is of utmost importance. To allow users to 
control and direct applications, menus will be used instead of commands. An attempt to 
incorporate the use of "mouse" environment will be pursued. 

Menu logic and materialization will not be included in this thesis. These will be 
covered fully in a separate User's Manual. 

Appendix D contains prototype samples of reports desired for this DBMS as 
discussed in section C of this chapter. These reports will be produced by the ESAAMS 
DBMS. 



61 



F. SUMMARY 



A DBMS is a software program that manipulates data in the database to produce results 
that a user requires for his business or work. In this chapter, a walkthrough of how the 
prototype ESAAMS DBMS will be designed has been covered Numerous challenges 
abound in the transformation of a hierarchical database model to a relational database 
model. The planning and design of correct objects or entities and their attributes and 
understanding of how the business of aviation maintenance is performed is important to the 
logical presentation of the whole database. 

A DBMS is only useful if it satisfies the needs of the users. This satisfaction can be 
derived if the system is easy to use, the system produces the right results and it meets the 
constraints that the users have in performing their business. 
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VIII. SUMMARY, CONCLUSIONS AND RECOMMENDATIONS 



A. SUMMARY 

To keep pace with the sophisticated and advanced technology of today’s aircraft and 
weapon systems, maintenance managers must have the tools, information, and data 
available to make accurate, knowledgeable, and expert decisions. The management tools 
and data support systems must be equally as sophisticated as the equipment they support 
but designed and constructed with a user interface which is a tool and not a hindrance to 
the process. 

A wealth of data is generated daily at all levels of maintenance. This data has been 
meticulously sorted and stored in various major databases throughout the Naval MDS. The 
problem does not lie with the quantity of data available to the maintenance manager but, the 
accessibility to this data and the transformation of this data into useful information. 
Present organizational maintenance management information systems simply do not have 
the capability to provide usable data at the time and in the form required to make accurate 
and timely decisions. The question presented to major project managers and the general 
focus of this research is on how to get information to the manager, in a timely and usable 
format, to assist in the critical decision making process. The introduction of NALCOM1S 
OMA will be the first significant step to satisfying this need. 

The NALDA database system contains the information necessary for decision making 
but suffers from an inherent time lag of 60 to 90 days. Access to the system can only be 
accomplished by on-line query or telephone requests to the user assistance group. While 
both of these vehicles are productive ways to access information, they do not provide 
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sufficient focus on the OMA. However, historical failure information and elapsed 
maintenance time are useful information. 

The purpose of this thesis was to identify the applicable data contained in the NALDA 
databases and design a user-friendly PC-based database for use with ESAAMS. A 
relational database constructed from the hierarchical structure of NALDA is one answer to 
providing NALDA data access to the OMA. Design, analysis and potential use of this 
database concept for ESAAMS has been provided in this thesis. The authors have also 
introduced the concept to the user maintenance professionals. Their opinions on aviation 
maintenance community information needs substantiate the focus of this research. 

The primary research questions addressed were: 

• What data contained in the NALDA database system are germane for use in building 

the ESAAMS main database? 

* What uses/benefits would such a database provide an organizational maintenance 

activity? 



Secondary questions that evolved from the research focus were: 

• Are other databases in addition to NALDA required for the proper operation and 

maximum benefit of ESAAMS? 

• What do the "experts" in the aviation maintenance community want from a 

management information system? 

B. CONCLUSIONS 

What data contained in the NALDA database system are germane for use 
in building the ESAAMS main database? 

The NALDA database contains voluminous amounts of data which includes 
information necessary to assist the maintenance expert to make more informed decisions. It 
contains all resource data entered daily on the VIDS/MAF, which is the primary source of 
information required by the maintenance manager. As discussed in Chapter IV, the 
NALDA FOJ database contains all the data germane for use in building the ESAAMS main 
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database. However, the time lag between a maintenance action reported at the O-Level and 
its availability for data retrieval from the NALDA system limits the utility of this database. 
This research has concluded that a stand-alone database management system using only the 
data contained in the NALDA database systems will have limited use and cannot support 
the Mai maintenance decision making process required in a dynamic aviation 
environment. 

The NALDA system is frequently used in the IMA to track the history of parts and 
assemblies throughout the maintenance/operation cycle. This level of maintenance tends to 
be not as dynamic as the O-level. The problem is that the NALDA system, in its present 
form, lacks real time capability. 

What uses/benefits would such a database provide an organizational 
maintenance activity? 

Access to real time information is the main desire that all maintenance managers have 
voiced in order to support the fast-paced evolution of aircraft maintenance. A specifically 
designed, stand-alone database like the one proposed in this thesis, will provide the OMA 
with a means of retrieving historical and trend data to assist the maintenance scheduling 
task. In the event of any communications failure or if communications are unavailable to 
the host system, this PC-based database can provide some of the needed data for decision 
support. The construction of the ESAAMS database from NALDA data is an important 
interim step toward accomplishment of the aviation maintenance information needs of the 
future. 

While the uses and benefits of a stand-alone system are limited and consume 
significant time, effort, and cost to produce, the construction of this prototype database is 
feasible and will achieve some benefit to the maintenance expert. This concept was 
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explored, not only to provide short term benefit to the maintenance manager, but, to 
evaluate the design and project requirements for ESAAMS in the long run. 

Are other databases in addition to NALDA required for the proper 
operation and maximum benefit of ESAAMS? 

This research has continually stressed the need for a real time capability, by any 
aviation maintenance information system, to enable maintenance managers to make real 
time decisions. The NAVAER 2010 Plan for total information systems (Figure 4-1 on page 
24) involves the NALDA/NALCOMIS/NADIM interrelation. NALDA will become the 
central database. This system design will enable the transmission and retrieval of real rime 
data to and from any potential user. 

NALCOMIS Phase III becomes the central player in this schema because it provides 
the necessary hardware to support the system at the OMA. Also, the NALCOMIS network 
provides the necessary links and protocols. Real time data management can be achieved 
using the NALCOMIS Phase III interface. 

NALCOMIS OMA in its optimal form, with ESAAMS as a subsystem application, 
will eliminate the inherent data time lag of the current NALDA system. Current source data 
will be available locally, in addition to access to the NALDA historical files. This 
combination eliminates any time lag in the retrieval and use of maintenance data. This 
corresponds directly with the preferences stated by the maintenance experts interviewed. 

What do the "experts" in the aviation maintenance community want 
from a management information system? 

Chapter VI discussed what some experts in the aviation maintenance community 

wanted from a management information system. They are: 

• User friendliness 

* Instantaneous access to data 
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• Real time computing 

• Single-system architecture (like NALCOMIS) 

Whatever information system is deployed for fleet use, a real rime link to the aviation 
maintenance data collection system should exist. To omit this feature will severely limit the 
utility of the system and decision support for the maintenance manager of the future. 



C. RECOMMENDATIONS 

Based upon research conducted in this thesis and the conclusions offered in the 

previous section, the following recommendations are offered: 

• Currently, OMA community knowledge of the NALDA system and its use is 

limited. Every OMA sh uld qualify a NALDA user for access to any NALDA 
database. This could be tied to the Data Analyst schooling providing an extra 
two weeks of instruction for NALDA use. This information returned to the 
squadron would fill the void now present in many organizations where little, if 
any, knowledge of the NALDA program exists.Presently there exists no direct 
access from OMA to NALDA except through IMA facilities. The NAVAIR 
2010 structure which links together the NALCOMIS/NALDA/NADLM systems 
should provide access at the OMA to facilitate on-line query capability. (See 
Figure 6-1 on p. 48) 

• Remove the policy of grading activities on aircraft readiness statistics which are 

derived from maintenance data input. This will encourage activities to report 
more accurate data and not promote "scrubbing" to improve readiness statistics 
as is the current practice. The quality of data contained in the various databases 
should improve quantifiably. thus allowing a more realistic picture when 
studying trends from the databases. 

• Link ECAMS and NALCOMIS OMA directly at the O-level to eliminate processing 

time and allow local use of the information on one system. The ECAMS 
system, or version thereof, is currently being implemented in several aircraft 
types. This rich source of data must be made available to the maintenance 
manager on the same real time basis as NALCOMIS information. This 
implementation would allow processing of data on a single system hardware 
suite vice the current two system setup. 

• Tie-in ESAAMS as a subsystem application to NALCOMIS OMA 

(see Figure 8-l).The authors believe that an expert advisory system can be 
designed and made to interface with the proposed NALCOMIS OMA structure. 
To facilitate this linkage, the structure of the NALCOMIS/NALDA database 
must be a functional, relational database structure. Such a change in database 
structure is currently in development at NAMO. Further research into the 
feasibility of such a link should be studied. This supports the original 
ESAAMS concept as envisioned by McCaffrey (1985). 
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APPENDIX A. OBJECT DIAGRAMS 
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NOTE: PRIMARY KEY 



APPENDIX C: OBJECT SPECIFICATIONS AND 

DEFINITIONS 



I. OBJECT DEFINITIONS 
A .END_ITEM 

TEC; Type Equipment Name 

BUNO; Aircraft Bureau Number 

TE_Name; Type Equipment Name 

Block; Equipment Production Block 

Maintenance_Action; Maintenance_Action object; MV; 

SUBSET [Julian Control Number, Work Center] 
Equipment_Simimary; Equipment_Summary object; MV; 

SUBSET [BUNO, Year-Month of Equipment Summary] 



B. MAINTENANCE_ACTION 

JCN; Julian Date Control Number 
WC; Work Center Number 

Action_Taken_Code; Maintenance Code for Action Taken 
AWM_Davs; Days Awaiting Maintenance 
AVVP_Days; Days Awaiting Parts 
EM I ; Elapsed Maintenance Time 
WUC; Work Unit Code 
Maint_Hrs; Maintenance Hours Performed 
Malfunction_Code; Maintenance Malfunction Code 
Num_Items; Number of Items Processed 
Recd_to_Comp_Day; Days from Receipt to Completion 
Recd_to_Inwork_Day; Days from Receipt to Inwork 
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Transaction_Code; Maintenance Transaction Code 
Type_Maintenance; Maintenance Type 
When_I)iscovered; Maintenance Code for When 
Discovered 

End_Item; End_Item object; SUBSET [TE_Name, TEC, 
BUNO] 

Incorporated_TD; Incorporated_TD object; MV; 

SUBSET fTD_Basic_Num] 

Job_ID; Job_ID object; 



C.EQUIPMENT_SUMMA T Y 

FMCM; Full Mission Capable Maintenance Hours 
FMCS; Full Mission Capable Supply Hours 
NMCS; Not Mission Capable Supply Hours 
NMCM; Not Mission Capable Maintenance Hours 
NMCMU; Not Mission Capable Maintenance Unscheduled 
Hours 

OPC; Optimum Performance Capable Hours 
PMCM; Partial Mission Capable Maintenance Hours 
PMCS; Partial Mission Capable Supply Hours 
Ship_F1ight; Number of Ship Operational Flight 
Ship_Flight_Hours; Ship Operational Flight Hours 
Total_Flight; Total Number of Flights 
Total_Flight_Hours; Total Number of Flight Hours 
YYMM_ES; Year and Month of Equipment Summary 
Endjtem; End_item object; SUBSET [BUNO, TEC, 
TE_Name] 
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I). J0B_I1) 



WTJC; Job Work Unit Code 
JCN_Org; Job JCN Maintenance Organization Code 
JCN_Yr_Day; Job JCN Year and Day 
JCN_YYMM; JOb JCN Year and Month 
JCN_SpIit; Job Split Numbered JCNs 
Maintenance_Action; Maintenance_Action object; MV; 

SUBSET I JCN, WC| 

E. INCORPORATED_TD 

TD_Basic_Num; Technical Directive Basic Number 
TD_Code; Technical Directive Code 
Amend_Num; Technical Directive Amendment Number 
Interim_Num; Technical Directiv Interim Number 
Kit_Num; Technical Directive Kit Number 
Review_Letter; Technical Directive Review Letter 
Maintenance_Action; Maintenance_Action object; 

SUBSET [JCN, WC] 

II. DOMAIN DEFINITIONS 
A. END ITEM 

1 . TEC - Type Equipment Code - identifies a complete End_Item. 

Text 4 

2. TE_NAME - Type of Equipment name - identifies Type/Model/Series of 
Equipment. 

Text 12 

3. Block - Production Block - identifier assigned by manufacturer to indicate 
aircraft that have been configured identically. 

Text 3 
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4. BUNO - Bureau Number - alphanumeric identifier for aircraft or equipment 
Text 6 

B. EQUIPMENT SUMMARY 

1. FMCM - Full Mission Capable Maintenance Hours - hours during a reporting 
period that equipment is full mission capable but not optimum performance capable, 
because of maintenance requirements existing on theinoperable subsystems. 

Numeric 3 

2. FMCS - Full Mission Capable Supply Hours - hours during a reporting period 
that equipment is full mission capable but not optimum performance capable, 
because maintenance required to clear the discrepancy cannot continue due to a 
supply shortage. 

Numeric 3 

3. NMCS - Not Mission Capable Supply Hours - hours during the reporting 
period that equipment is not capable of performing any of its missions because 
maintenance required to clear the discrepancy could not continue due to a supply 
shortage. 

Numeric 3 

4. NMCMS - Not Mission Capable Maintenance Scheduled Hours ■ hours during 
reporting period that equipment is not capable of performing any of its missions 
due to scheduled maintenance requirements. 

Numeric 3 

5. NMCMU - Not Mission Capable Maintenance Unscheduled Hours - hours 
during reporting period that equipment is not capable of performing any of its 
missions because of unscheduled maintenance requirements. 

Numeric 3 

6. OPC - Optimum Performance Capable Hours - hours during reporting period 
that equipment is in optimum performance capability status. 

Numeric 3 

7. PMCM - Partial Mission Capable Maintenance Hours - hours during reporting 
period that equipment is capable of performing at least one but not all of its 
missions because of maintenance requirements existing on the inoperable 
subsystems. 
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Numeric 3 

8. PMCS - Partial Mission Capable Supply Hours - hours during reporting period 
that equipment is capable of performing at least one but not all of its missions 
because maintenance cannot continue due to supply shortage. 

Numeric 3 

9. Ship_Flight - The number of individual ship operation flights that an aircraft 
has accumulated during the reporting period. 

Numeric 3 

10. Ship_Flight_Hrs - Portion of the total flight hours, rounded to the nearest 
whole number, accumulated on an aircraft while involved with ship operations 
during the reporting period. This includes all flight hours for flights that originate, 
terminate or involve a ship (i.e., a flight originates at a shore station, flies to a ship, 
lands and takes off to shore), and will be reported as ship operations. 

Numeric 3 

1 1. Total_Flight_Hrs - Number of flying hours, rounded to the nearest whole 
number, accumulated on an aircraft, during the reporting period. 

Numeric 3 

12. Total_Flights - Number of individual flights that an aircraft has accumulated 
during the reporting period. 

Numeric 3 

13. YYMM_ES - Year and month for which the equipment summary record was 
generated. 

Numeric 4 

C. INCORPORATED TD 

1. TI)_Basic_Num - Technical Directive Basic Number - number assigned by 
Naval Air Technical Services Facility (NATSF) to identify the Technical Directive 
which has been approved by the Change Control Board. Numbers are assigned 
sequentially from 0001 by the Technical Directive Code within the aircraft type 
model. 

Text 4 
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2. TD_Code - Technical Directive Code - code identifying a type of Technical 
Directive and system to which it is applicable. 

Text 2 

3. Amend_Num - Amendment number - identifies the document that clarifies, 
corrects, adds to, deletes from, makes minor changes in requirements to, or cancels 
an existing Technical Directive. 

Text 1 

4. Interim_Num - Interim Number - code indicating that the Technical Directive 
is an interim change. 

Text 1 

5. Kit_Num - Kit Number - alphanumeric character that identifies a particular kit 
associated with a particular Technical Directive. 

Text 2 

6. Review_Letter - Character that identifies the revision number of the Technical 
Directive. The character identifier is blank if the Technical Directive is not a 
revision. 

Text 1 

D. .lob ID 

1 . WUC - Work Unit Code - alphanumeric code that identifies the component or 
end item on which maintenance was performed. 

Text 7 

2. JCN_Org - Job Control Number Organization - alphanumeric code that 
identifies the organization that originated the Job Control Number. 

Text 3 

3. JCN_Yr_Dav - Job Control Number Julian Year Day - the Julian date (YYDD) 
that the JCN was initiated. 

Numeric 5 

4. JCN_YYMM - Job Control Number Julian Year Month - the Julian date in year 
and month (YYMM) that the JCN was initiated. 

Numeric 4 
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5. Split_JCN - Split Job Control Number - identifies multiple jobs, identifiable as 
separate valid transactions which are reported with the same JCN. When multiples 
occur, split_JCN is valued in each multiple job in the sequence A to Z, 0 to 9. 

Text 1 

E. Maintenance Action 

1. Action_Taken_Code - code indicating action taken in performance of a 
maintenance action. I.E., repair, corrosion prevention, etc. 

Text 1 

2. AWM_Days - Awaiting Maintenance days - total number of days a job was in 
an awaiting maintenance status. Awaiting maintenance status is a summary of all 
statuses having a status of 0 hrough 9 associated with a single 

Numeric 4 
Number of decimal 1 

3. AWP_Davs - Awaiting Parts Days - total number of days a job was in an 
awaiting parts status. Awaiting parts status is defined as a summary of all statuses 
with a job status of "S" for a single maintenance action. 

Numeric 4 

Number of Decimal 1 

4. EMT - Elapsed Maintenance Time - total elapsed clock hours for "in work” 
time. 

Numeric 5 

Number of Decimal 1 

5. WUC - Work Unit Code -alphanumeric code that identifies the component or 
end item on which maintenance was performed. 

Text 7 

6. Maint_Hours - Maintenance Manhours - total number of manhours spent 
performing a maintenance action. 

Numeric 5 

Number of Decimal 1 

7. Malfunction Code - Code describing the malfunction which necessitated the 
maintenance action. 
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Numeric 3 

8. Num_Items - Number of Items processed - total number of items processed as 
a result of the maintenance action. 

Numeric 2 

9. Recd_to_Comp_Day - Receipt to completion day - total number of days from 
received day and time to the completion data and time. 

Numeric 4 

Number of Decimal 1 

10. Recd_to_In_work_Day - Receipt to In-work day - total number of days 
from the received date and time to the In-work date and time. 

Numeric 4 

Number of Decimal 1 

1 1. Transaction_Code - code indicating the type of maintenance data reported. 
I.E., on equipment work, inventory, etc. 

Numeric 2 

12. Type_Maintenance - Type of maintenance code - code indicating the type of 
maintenance performed. I.E., scheduled maintenance, unscheduled maintenance, 
etc. 

Text 1 

13. When _Discovered - When discovered code - code indicating when the 
discrepancy was discovered. I.E., in-flight, pre-flight, etc. 

Text 1 

14. WC - Work Center - code identifying the work center that performed the 
maintenance action. 

Text 3 

15. JCN - Job Control Number - the alphanumeric characters assigned to specific 
maintenance requirement utilized for maintenance action tracking. 

Text - 1 1 
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APPENDIX D. SAMPLE REPORTS/FORMS 
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